Decentralized nodal network for providing security of files in distributed filesystems

ABSTRACT

A secure method of maintaining and accessing files (for example, multimedia files) is provided. Each file is divided into fragments or slices and each slice is encrypted and stored on a separate node. Each node is also required to maintain an instance of a public block-chain (or distributed ledger) which holds conventional block-chain transaction information for managing payment for access to the files. Preferably, each node is also paid in digital currency both as a conventional block-chain miner for maintaining the public block-chain and also for maintaining the slices.

This application claims priority to U.S. Provisional Application Ser.No. 62/422,641, filed Nov. 16, 2016, and entitled Decentralized NodalNetwork For Providing Security of Files in Distributed Filesystems, theentire disclosure of which is hereby incorporated by reference.

FIELD OF THE INVENTION

This application relates to improvements for providing secure storageand transmission of files in a computer system utilizing encryption andblock-chain techniques.

BACKGROUND

Cryptographic systems are known for providing secure transmission offiles such as media files. Examples of media files include, for example,audio files, image files, and video files. Public key cryptography orasymmetric cryptography refers to cryptographic systems that use pairsof keys: public keys which may be disseminated widely, and private keyswhich are known only to the owner.

Cryptographic systems are also used in financial transactions. One suchsystem is known as “bit coin,” described in Satoshi Nakamoto, Bitcoin: APeer-to-Peer Electronic Cash System, www.bitcoin.org (2009),incorporated herein by reference in its entirety. In the bitcoin system,an important element is the block-chain, which is a type of distributedledger. The block-chain records financial transactions which have beenexecuted using bitcoins. No central authority intermediates therecording of financial transactions in the bitcoin system. Rather,bitcoin software is installed on a large number of devices (which may ormay not be computer servers) connected via the Internet. The financialtransactions (which can be considered in the form: “payer A wants tosend Z bitcoins to payee B” are broadcast to devices on the network. Thedevices validate these financial transactions, add a record of them totheir copy of the block chain, and then broadcast these block-chainadditions to other servers of the network. Each block in a block chaincontains hold batches of transactions. Each block includes the hash ofthe prior block in the block-chain, linking the two. In addition to asecure hash based history, a block-chain database has a specifiedalgorithm for scoring different versions of the history so that one witha higher value can be selected over others. Furthermore, block-chainsuse various time-stamping schemes, such as proof-of-stake or proof ofwork to serialize additions or changes in the block-chain.

As noted above, a block-chain is a type of distributed ledger. However,as noted in Investopedia, distributed ledger can more generally bedescribed as a ledger of any transactions or contracts maintained indecentralized form across different locations and people, eliminatingthe need of a central authority to keep a check against manipulation.”(http://www.investopedia.com/terms/d/distributed-ledgers.asp) Further,“the information on it is securely and accurately stored usingcryptography and can be accessed using keys and cryptographicsignatures. Once the information is stored, it becomes an immutabledatabase and is governed by the rules of the network.” A blockchain is aform of a decentralized or distributed ledger, but blocks of data neednot be “chained” together to constitute a distributed ledger.

Maintaining the block chain or distributed ledger is referred to as“mining”, and the “miners” (or more particularly, the mining nodes inthe system) are awarded newly created bitcoins and transaction fees inreturn for mining the block-chain. Mining includes confirming thevalidity of transactions received over the network, and adding them tothe block they are creating, and then broadcasting the completed blockto other nodes. Techniques for maintaining and mining a block-chain aredescribed for example, in WO 2015/077378A1, and US 2015/0356555 A1,which are hereby incorporated by reference in their entirety.

In the Bitcoin system, bitcoins can be kept in what is often referred toas a digital wallet, which is a computer program which “holds” or“stores” bitcoins. However, in the Bitcoin system, bitcoins areinseparable from the block chain or distributed ledger. Accordingly, abitcoin wallet is a program which stores digital credentials for a givenuser's bitcoin holdings and allows that user to access and spend them.The Bitcoin system utilizes asymmetric cryptography, in which twocryptographic keys, one public key and one private key, are generated. Abitcoin wallet includes a collection of these keys, and typically alsoincludes functionality to make bitcoin transactions.

Bitcoin wallet software, sometimes referred as being “bitcoin clientsoftware”, allows a given user to transact bitcoins. A wallet programgenerates and stores private keys, and communicates with peers on thebitcoin network. An early wallet program called “Bitcoin-Qt” wasreleased in the year 2009 by Satoshi Nakamoto as open source code;Bitcoin-Qt is also sometimes referred to as “Satoshi client”. The walletprogram can be used as a desktop wallet for payments or as a serverutility for merchants and other payment services.

SUMMARY OF THE INVENTION

In accordance with a first embodiment of the present invention, a systemis provided including a server and a plurality of computer nodesinterconnected via the internet, which provides a secure method ofmaintaining and accessing files. Also provided are methods for operatingthe server and computer nodes, and non-transitory computer readablemedia for providing a secure method of maintaining and accessing files,comprising a first computer readable media including first computerexecutable process steps operable to control a server computer, and asecond computer readable media including second computer executableprocess steps operable to control a computer node.

The first computer executable process steps are operable to control theserver computer to perform steps including: dividing each of a pluralityof files into unique file fragments or slices, encrypting each of theunique slices, distributing the unique slices to a plurality of computernodes executing the second computer executable process steps such thatno currently connected node receives all of the unique slices. In somevariants, each computer node receives at least one of the unique slices.In other variants, only a subset of the active nodes may receive theunique slices. In either case, no currently connected node receives allof the unique slices or fragments. In the context of the presentapplication, the terms “slices” and “fragments” are synonymous.

The first computer executable process steps also include distributingblock chain (or distributed ledger) transactions to each of theplurality of computer nodes, wherein the block chain (or distributedledger) transactions information for managing payment and access to thefile fragments. The first computer executable process steps also includegenerating assembly information for each of the plurality of files,wherein the assembly information includes information sufficient toreassemble an instance of a file of the plurality of files from theunique slices associated with said file. In this regard, the assemblyinformation may be stored in the blockchain, elsewhere on the nodes, oron a server or another computer on the network. The first executableprocess steps may also include communicating with the nodes to retrievethe assembly information sufficient to reassemble an instance of a fileof the plurality of files from the unique slices associated with saidfile.

Although reference is made herein to “blockchains” and “blockchaintransactions”, it is to be understood that the present invention isequally applicable to other types of distributed ledgers, including,without limitation, distributing distributed ledger transactions,maintaining a distributed ledger and mining a distributed ledger.

In some variants, the plurality of nodes includes each connected node inthe network, and in other variants, the plurality of nodes may includeonly a subset of the connected nodes, such that not every connected nodenecessarily receives a slice.

The second computer executable process steps are operable to control thecomputer node to perform steps comprising receiving and storing at leastone of the encrypted unique slices which constitute each file of theplurality of files, but not all of the encrypted unique slices thatconstitute any one of said files; maintaining an instance of a publicblock-chain; and receiving and mining or executing the block chain (ordistributed ledger) transactions from the server. In accordance withfurther optional aspects of this embodiment, the first computerexecutable process steps are operable to control the server computer toperform steps including paying each of the computer nodes in digitalcurrency for mining and maintaining the public block chain (ordistributed ledger) and for receiving storing the unique file fragmentsor slices. Each computer node preferably includes the second computerexecutable process steps.

In one variant of the above-referenced embodiment, the network includesN nodes, the files divided into slices of a predefined size, and theslices are distributed to some or all of the N nodes, wherein no singlenode holds more than 25% of the total number of slices stored on thenetwork on N nodes. In other variants no single node holds more than 25%of the slices of any file.

In accordance with an alternative variant, the server specifies aminimum file size requirement per node (in kilobytes) is Fsr=Fsn/N−Awhere Fsr=File size required per node (in kilobytes), Fsn=Total size ofall files on the network (in kilobytes), N=total number of nodes on thenetwork and A=Additional storage space which is voluntarily madeavailable at the nodes.

In accordance with a second embodiment of the present invention, asystem and computer implemented method of securely managing files amonga plurality of computer nodes connected to a server over an peer-to-peernetwork or over an internet is provided. Also provided arenon-transitory computer readable media having stored thereon computerexecutable process steps for performing the method. The method comprises(a) receiving a plurality of files from one or more of the nodes; (b)determining a number of the plurality of nodes currently connected tothe server; (c) for each of the plurality of files: dividing the fileinto a number of unique slices (or fragments) of predetermined size,encrypting each of the unique slices, distributing the unique slices toa number of the currently connected nodes such that no currentlyconnected node receives all of the unique slices; and (d) repeatingsteps (b) and (c).

In one variant, in step (c) the unique slices (or fragments) aredistributed to a minimum number of the currently connected nodes suchthat no currently connected node receives all of the unique slices inaccordance with minimum fragment replication parameters. In this regard,exemplary minimum fragment replication parameters include sending eachfragment to a predefined number of nodes, thus replicating the fileacross the nodes providing redundancy should one of the nodes beunavailable. Distributed Hash Tables (DHTs), such as those used in Storjand IPFS (discussed below), may be used for tracking and distributingfile fragments to nodes.

In another variant, in step (c) the number of unique slices is equal toat least a minimum number of nodes, the minimum number of nodes is setto a value no less than 100, preferably no less than 500, and morepreferably no less than 1000, and no currently connected node receivesall of the unique slices.

In another variant, in step (c) the number of unique slices is equal toat least the number of nodes and the unique slices are distributed toall of the currently connected nodes such that each currently connectednode receives at least one of the unique slices, and no currentlyconnected node receives all of the unique slices;

In accordance with further optional aspects of the first and secondembodiments, the plurality of files are media files selected from audiofiles, video files, text files, image files, and audio-video files.

In accordance with other and/or further optional aspects of the firstcomputer executable process steps of the first embodiment, and themethod of the second embodiment, the steps further include (a) receivinga request for a first file of the plurality of files from a first nodeof the plurality of nodes; (b) transmitting a private encryption key tothe first node; (c) retrieving the unique slices corresponding to thefirst file from the currently connected nodes; (d) decrypting the uniqueslices; (e) accessing assembly information for the first file; (f)reassembling the unique slices into an instance of the first file; (g)encrypting the instance with a public key associated with the privatekey; and (h) transmitting the instance to the first node.

In accordance with other and/or further optional aspects of the firstcomputer executable process steps of the first embodiment, and themethod of the second embodiment, the steps further include transmittingthe assembly information to each of the plurality of connected nodes asa block-chain transaction, and the block-chain transaction may alsoinclude information indicative of a price of the first file and/or aviewing limit for the first file. Further, the steps may further includedestroying the instance when the viewing limit is exceeded.

In accordance with other and/or further optional aspects of the firstcomputer executable process steps of the first embodiment, and themethod of the second embodiment, the steps may also include receivingpayment for the instance in crypto-currency. The steps may also comprisetransmitting payment in crypto-currency to an owner of the first file,where the step of transmitting payment comprises sending a block-chaintransaction to each of the connected nodes.

In accordance with other and/or further optional aspects of the firstcomputer executable process steps of the first embodiment, and themethod of the second embodiment, the steps may also include transmittingpayment in crypto-currency to an owner of each of the plurality ofnodes, where the step of transmitting payment comprises sending ablock-chain transaction to each of the connected nodes, wherein anamount of said payment is proportional to an amount of storage on eachnode allocated to storing the unique slices. Further, the payment mayalso proportional to an amount of block-chain mining performed by eachnode.

In accordance with other and/or further optional aspects of the firstcomputer executable process steps of the first embodiment, and themethod of the second embodiment, the steps may also include transmittingpayment in crypto-currency to an owner of each of the plurality ofnodes, where the step of transmitting payment comprises sending afurther block-chain transaction to each of the connected nodes, whereinan amount of said payment is proportional to an amount of block-chainmining performed, and preferably proportional to an amount of storageallocated by each node to storing the unique slices.

In accordance with a third embodiment of the present invention, a systemand computer implemented method of securely managing files on a computernode of the network is provided. Also provided are non-transitorycomputer readable media having stored thereon second computer executableprocess steps for performing the method. The steps comprise: (a)providing, on a computer, an instance of a public block chain (ordistributed ledger); (b) receiving, from a server, for each of aplurality of files, a first transmission of at least one of a pluralityof unique slices which constitute said each file, but not all of theplurality of unique slices which constitute said each file, wherein eachunique slice is encrypted when received; (c) storing each of thereceived unique slices in memory; (d) receiving, from a server, for eachof a plurality of files, a subsequent transmission of at least one of aplurality of unique slices which constitute said each file, but not allof the plurality of unique slices which constitute said each file,wherein each unique slice is encrypted when received; (e) discarding theunique slices stored in step c and storing in memory the unique slicesreceived in step d; (f) receiving a block-chain transaction containingassembly information and payment information for one of the plurality offiles; and (g) mining the block-chain using the block-chain transactionreceived in step f.

In accordance with a fourth embodiment of the present invention,non-transitory computer readable media are provided which comprise firstcomputer readable media including first computer executable processsteps operable to control a server computer as described above theregard to the first and/or second embodiments, and second computerreadable media including second computer executable process stepsoperable to control a computer node as described above with regard tothe first and third embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary system diagram for an embodiment of thepresent invention.

FIG. 2 illustrates how increasing the number of nodes increases thenumber of slices, reduces the size of each slice, and reduces the slicestorage requirements for each node.

FIG. 3 is an illustrative flow chart for owner and user processes forthe system of the embodiment of FIG. 1.

FIG. 4 is an illustrative flow chart which illustrates the uploading ofa multimedia file, dividing it into slices, distribution to nodes, andreassembly as a file instance.

FIG. 5 is an illustrative flow chart which illustrates the accessing,and optional destruction of, a file instance.

FIGS. 6(a) to 6(c) illustrates the relationship between the number ofnodes, number of files, number of slices, file size per slice, and filesize requirements per node for in the context of storage of exemplaryTelevision episodes.

FIGS. 7(a) to 7(c) illustrates the relationship between the number ofnodes, number of files, number of slices, file size per slice, and filesize requirements per node for in the context of storage of exemplarymusic files.

FIG. 8 is a flow-chart providing an illustrative method of mining ablock chain.

FIG. 9 is a flow-chart providing an illustrative method of performing aproof of stake (or proof of work) for the method of FIG. 8.

DETAILED DESCRIPTION

In accordance with an embodiment of the present invention, a securemethod of maintaining and accessing files (for example, multimediafiles) is provided. Each file is divided into fragments or slices andeach slice is encrypted and stored on a separate node. As used herein,the terms “slice[s]” and “fragment[s]” are used synonymously. Each nodeis also required to maintain an instance of a public block-chain (ordistributed ledger) which holds conventional block-chain transactioninformation for managing payment for access to the files. Each node alsopreferably holds assembly information for reassembling the slices intothe files, either as part of the block-chain, or separately. Preferably,each node is also paid in digital currency both as a conventionalblock-chain miner for maintaining the public block-chain and also formaintaining the slices.

FIG. 1 illustrates a system according to an embodiment of the presentinvention, including a plurality of user node computers 20, a pluralityof owner node computers 30, and a backend server 40 interconnected viathe internet 30 to form a network. Although we refer to a “node computer10”, it should be understood that each node could in fact be comprisedof a network of computers. Similarly, although we refer to a “server”,the server computer could in fact be implemented as a network of servercomputers.

Each node 10 and 20 (owner and user) is responsible for mining andmaintaining an instance of the public block chain (or distributedledger), and for maintaining a plurality of the encrypted slices. Thebackend server 40 is responsible for dividing the files into slices,encrypting the slices and distributing the encrypted slices to the nodes10, 20. Each slice is “unique” in the sense that it needs to bereassembled in a particular sequence with the other slices toreconstitute the file. The backend server 40 also generates assemblyinformation for each file, and is responsible for broadcasting theassembly information to the nodes 10, 20, preferably as a block-chaintransaction (“assembly block-chain transaction”) for publication in thepublic block-chain. Each of the nodes 10, 20 also implements a digitalwallet for managing payment for access to the files and payment of minerfees for mining the block-chain and maintaining the slices.

As one of ordinary skill in the art will appreciate, commerciallyavailable software is available which can divide a file into slices orfragments, including, for example, Storj, IPFS, LxSplit, and HJ-Split,which are described in the following publications, incorporated hereinby reference: Shawn Wilkinson et al, Storj, A Peer-to-Peer Cloud StorageNetwork (Dec. 15, 2016), Gabriel Comte, LIBRARY DEVELOPMENT FOR STORJCLOUD CLIENTS IN UNSUPPORTED ENVIRONMENTS (2017); Lxsplit,http://lxsplit.sourceforge.net/(Oct. 17, 2008); Manual For HJSplit forWindows, http://www.freebyte.com/hjsplit/manual/(Dec. 3, 2010), Benet,IPFS—Content Addressed, Versioned, P2P File System (DRAFT 3) (Jul. 14,2014).

In one variant of the present invention, the number of nodes on thenetwork preferably is equal to the number of fragments or slices that afile is split into, and each node holds at least one slice from eachfile. To implement this, the backend server monitors the number ofactive nodes (defined as nodes logged on to the network), andcontinually repeats the process of dividing the files into slices,encrypting the slices (preferably using AES-128 or AES-125 encryptionprotocols to enhance file security) and distributing the encryptedslices to the active nodes. Preferably, this would be done in responseto changes in the status of nodes. For example, when a node goesoffline, it will send an alert to the backend server which willrecalculate and redistribute the number of slices. Similarly, when anode comes online, it will send an alert to the backend server as wellwhich will similarly recalculate and redistribute the slices amongst thenodes. Utilizing an alert-based system ensures that the appropriatenumber of slices are on the entire population of nodes at any giventime. Alternatively, this process can be repeated at fixed intervals(e.g., every 5 seconds, 3 seconds, 1 second). It should be noted thatsince the block chain transaction (which includes the assemblyinformation, price and time of access information, and timestamp) ispublished in the public block-chain, it does not need to be resent.

In any event, when a node receives an updated set of encrypted slices,it discards the prior set of encrypted slices. The system requires eachnode to allocate a minimum amount of storage size proportional to thetotal number of active nodes and the total size of all files on thenetwork.

In another variant of the present invention, the number of nodes on thenetwork preferably is not necessarily equal to the number of fragmentsor slices that a file is split into. To implement this, the backendserver monitors the number of active nodes (defined as nodes logged onto the network), encrypts the slices (preferably using AES-128 orAES-125 encryption protocols to enhance file security) and distributesthe encrypted slices to some or all of the active nodes in accordancewith minimum fragment replication parameters. In this regard, exemplaryminimum fragment replication parameters include sending each fragment toa predefined number of nodes, thus replicating the file across the nodesproviding redundancy should one of the nodes be unavailable. When a nodereceives an updated set of encrypted slices, it discards the prior setof encrypted slices. The system requires each node to allocate a minimumamount of storage size, preferably about 100 MB.

The systems and methods according to the various embodiments of thepresent invention may provide a decentralized and anonymous system whichwill allow for the control, storage, security and exchange of multimediafiles. The system can be used by users and multimedia owners to securelyexchange information and prevent piracy through the use of a pluralityof user and owner nodes, each managing a public block-chain and storingan encrypted slice of each multimedia file. The system may also providemultimedia owners with the ability to set predetermined prices for theirintellectual property, preferably through functions executing on theowner nodes.

The system may also provide users and multimedia owners with the abilityto interact and exchange property stored on a nodal network for fiatcurrency. In this regard, each of the user and owner nodes may beprovided with a digital wallet (e.g., a bitcoin wallet or Ethereumwallet, as examples) for exchanging fiat currency for crypto-currency(herein referred to as “slice currency”), and for executing financialtransactions using the public block-chain. The nodes are rewarded inslice currency both for storing file slices and processing transactionson the block-chain. The slice currency can then be used to accessmultimedia or transferred into alternate (e.g. fiat) currencies by thebackend server for an exchange fee.

Preferably, the system enables the establishment of contracts betweenmultimedia artists and users that is stored and processed on the publicblock-chain. For example, this functionality could be integrated intothe user and owner nodes, either in the digital wallet or in a separateprogram. For example, Ethereum (https://www.ethereum.org) providesEthereum Wallet which allows users to hold and secure crypto-assets, aswell as to write, deploy and use smart contracts.

The organization of the system of FIG. 1 will now be described infurther detail. The system requires at least two nodes to be active inorder to operate. However, the system is designed to leverage thousandsof nodes in order to increase processing time and decrease node storagerequirements. Two alternative implementations will be described inreference to FIG. 1.

In a first implementation, each node will be responsible for maintaininga minimum available storage space. Nodes can opt to allocate additionalnetwork storage space in exchange for additional crypto currency.

In a second implementation, each node will be responsible formaintaining storage space for a certain size of file slices which isproportional to the number of nodes (user and owner) in the network.Nodes can opt to allocate additional network storage space in exchangefor additional slice currency. This additional network space will reducethe minimum file size per node. Preferably, the equation for the minimumfile size requirement per node (in kilobytes) is Fsr=Fsn/N−A whereFsr=File size required per node (in kilobytes), Fsn=Total size of allfiles on the network (in kilobytes), N=total number of nodes on thenetwork and A=Additional storage space allocated by miners.

In this second implementation, each node is responsible for at least oneslice per file. For example, if there are 1000 files on a network of1000 nodes, and no node has allocated additional storage space (A=0),each node would be responsible for 1 slice per file, and there would be1,000,000 file slices. This architecture is advantageous because itallows for a constant number of file slices to be distributed evenlyamong the entire network of nodes. Further, because each node has atleast one slice of every file, any attempt to hack the system wouldrequire the hacker to breach every single node on the network, as everynode has a slice of each file. FIG. 2 illustrates how, in a system with3500 files, increasing the number of nodes increases the number ofslices, reduces the size of each slice, and reduces the slice storagerequirements for each node.

In both implementations, the system preferably enforces a limit on theamount of additional storage that can be allocated at any given node, inorder to ensure that the distribution of slices is such that no singlenode maintains an unacceptably large portion of the slices of file. Incertain variants, preferably, no single node can be allocated no morethan 25%, preferably no more than 10%, and more preferably no more than5% of the total network storage. In other variants, preferably no singlenode can be allocated no more than 25%, preferably no more than 10%, andmore preferably no more than 5% of the slices of a file.

Each node (e.g., which may include user and owner nodes) storingfragments or slices preferably acts as a block-chain miner and isresponsible for processing a number of transactions occurring on thepublic block-chain. Techniques for mining and updating block-chains arewell known, and accordingly are not repeated in detail herein. Mining ispreferably implemented into a GUI application at the node. Through abackground process, the application will process transactions and keeptrack of the time and size of storage allocated. Miners will be rewardedfor transactions per second as well as size allocated per second. Thenumber of transactions required per miner is proportionally dependentupon the number of transactions demanded, and changes based on thenumber of active nodes on the network. Preferably, the formula is: P=T/Nwhere P=Number of transactions processed, T=Number of queuedtransactions, and N=Number of active nodes.

Each node is preferably rewarded based on the number of the transactionsit processes and based on the network storage space allocated in thenode for slices. Preferably, the award is constant in order toincentivize miners to mine on the block-chain and to support thetransactions in the system. As an arbitrary example, miners might beawarded one slice per 100,000 transactions processed as well as oneslice per 1,000 file slices stored per node per day. The reward valuesare based on the parameters set when creating the Genesis block (i.e.,the first block of a block-chain). For example, one block of Bitcointransactions contains a reward of 12.5 bitcoins currently. In thebitcoin network, the time to process a block of transactions is staticand the difficulty variable adjusts accordingly to maintain the processtime. The systems described herein in accordance with the presentinvention can be implemented in a similar fashion.

As discussed above, in one variant, each node stores, in addition to itsinstance of the block-chain, encrypted slices which are received fromthe backend server. At the backend server, each file is divided into anumber of slices and the slices are encrypted before being distributedto the nodes. Advantageously, each slice is encrypted using the smallest(in terms of bit size) available encryption algorithm based on number ofslices to allow for maximum security while also maintaining viability ofeach node. Preferably an AES-128 or AES-125 encryption algorithm can beused. In another variant, each node stores, in addition to its instanceof the block-chain, encrypted slices which are received from the backendserver. At the backend server, each file is divided into a number ofslices of a predetermined size and the slices are encrypted before beingdistributed to a predefined minimum of nodes to insure availability ofreplication of all the slices (or fragments) required to reassemble theoriginal file. Advantageously, each slice is encrypted using thesmallest (in terms of bit size) available encryption algorithm based onnumber of slices to allow for maximum security while also maintainingviability of each node. Preferably an AES-128 or AES-125 encryptionalgorithm can be used.

A process for using the system will now be described from theperspective of the users and owners with reference to the flow charts ofFIGS. 3-5.

Using a graphical user interface (GUI) executing on the owner node, anowner 101 sets the price (step 102) for a media file(s) and uploads themedia file(s) (step 103) to the Backend Server. At the back end server,each file 104.1 is divided into a plurality of slices and encrypted104.2, and distributed to the nodes. In the first variant, at least oneslice for each file is transmitted to each node in the network (step105). In the other variant, the slices are distributed to a predefinedminimum of nodes to insure availability of replication of all the slices(or fragments) required to reassemble the original file. The back endserver also generates assembly information for each file which indicateshow the slices are to be combined to recreate the file as a multimediafile instance 113. Exemplary publically available software products fordividing a file into fragments or slices and generating assemblyinformation is “lxsplit” available from Source Forge(www.lxsplit.sourceforge.net) and from “hjsplit” available from Freebyte(www.hjsplit.org/linux), Storj (https://storj.io/), and IPFS(https://ipfs.io/), . . . Encryption may, for example, be implementedwith an AES encryption (Advanced Encryption Standard) algorithm such asan AES-125 or AES-128 algorithm. This assembly information, along withthe public key (i.e., the public key for the transaction sender, in thiscase the Backend Server), transaction time, price and time setting (i.e.the price and time period for the lease of the file), and payor andpayee information, is incorporated into to a block-chain transactionwhich is broadcast to all nodes when a file is purchased by a user.Alternatively, instead of the assembly information, other informationsufficient to identify the file can be included in the transaction. Inany event, each node then mines the block-chain transaction andmaintains its instance of the public block-chain in a conventionalmanner. At this point, each node in the system includes an instance ofthe block-chain (which includes the assembly and other transactioninformation) as well as at least one encrypted slice for each file inthe system. Although the assembly information is preferably incorporatedinto the block-chain, it can alternatively be stored elsewhere in thenodes or on the backend server.

Using a graphic user interface (GUI) executing on a user node, a user106 deposits fiat currency (step 107). This fiat currency is thenconverted to slice currency through interaction between the GUI andbackend server in a conventional manner (step 108). The user thenselects a desired media file through the GUI (step 109). A privatedecryption key is generated by the Backend server and sent to the userGUI, and the slice currency is debited from the user account (step 111).Using the decryption key, the Backend Server creates a file instance(step 112). The backend server then uses the assembly information toidentify and locate the slices, retrieves and decrypts the slices 104.2from the nodes, assembles the slices into an instance of the media file112.1, and streams (or, alternatively, downloads) the media file to theuser (step 113). This transaction is published in the block-chain bybroadcasting an assembly transaction to the nodes (as described above),which in turn, mine and update the public block-chain.

Payment for the purchase is then deposited as slice currency to theowner's account, preferably via the same block-chain transaction (step114). Alternatively, payment could be made in a separate block-chaintransaction. This slice currency can then converted to fiat currencythrough interaction between the GUI and backend server in a conventionalmanner. If the file instance was leased or streamed for a limited timeor limited number of downloads (e.g. a use limitation), the fileinstance is destroyed (step 115) when the use limitation is exceeded.

Returning to steps 110 and 112, each file instance has its own encryptand decrypt key. In addition, each slice is encrypted, as is the blockchain (or distributed ledger). The decryption keys will be exchangedbetween owners and users automatically in the background using theGraphic User Interface (GUI) using conventional techniques. Eachencryption and decryption key will exist for one instance of thecontract (sale, lease) between the owner and users, and will expire whenthe contract expires to prevent piracy. Each User and Owner key may beset to expire after a time interval after which they will change to addanother layer of security. The arrangement in which the file isassembled from the slices creates a new instance of a transaction andfurther adds to security because each new instance is attributed its ownencrypt key and decrypt key with which to unlock the file. Thisarrangement of encryption and decryption creates hundreds of millions ofdifferent possible instances for each individual file and utilizesredundancy to increase access time and security. This is preferablyimplemented into the backend server. When a file is purchased foraccess, the backend server uses the assembly information to identify thefile slices, decrypts the slices using generated decrypt keys, andgenerates a new instance of the file with a public key which correspondsto the private key sent to the user. The backend server essentiallycreates an encrypted “snapshot” or stream of the file based on theassembly of slices. This “snapshot” will be assigned a decrypt key (bythe backend server) which grants the purchaser access to the file. Theuser, through a background process in the GUI, uses the decrypt key todecrypt the file instance.

In one variant, the decrypted snap shot is stored on the purchasersnode, and once the file is no longer contractually available, thedecrypted “snapshot” is destroyed or made inaccessible usingconventional DRM (Digital Rights Management) techniques. Once thetransaction is initiated, it is then processed on the public block-chainand recorded to prevent theft and piracy as described above.

In another variant, once the file is accessed, the “snapshot” isdestroyed, and the backend will create a new “snapshot” for eachsubsequent transaction. Then, after the allotted time interval, thebackend server destroys the file instance. Once the transaction isinitiated, it is then processed on the public block-chain and recordedto prevent theft and piracy as described above.

Additionally, the user node may utilize daemons to analyze and determinewhether additional recording equipment is connected, and will preventmedia streaming if detected. This provides an additional layer ofsecurity.

As an additional security option, the assembly information itself may bedivided into slices by the backend server, encrypted and sent to thenodes in the same manner as the file slices. The backend server wouldthen maintain a record of the arrangement of the assembly informationslices, and access them in the same manner as described above withrespect to the file slices. In particular the system could include onenodal network that distributes file slices to nodes and a separate nodalnetwork that distributes assembly information of the slices to nodes.The two nodal networks would be connected to each other and communicatewith each other in terms of number of files/slices that are on thenetwork as well as the information for how the slices can be assembled.In this way all of the critical information for the forming of the filecould be decentralized and secure rather than on one backend servercomputer. In this case, slice assembly information would be extrapolatedfrom one nodal network and sent to the second nodal network whichactually stores the slices. The second network would thenassemble/disassemble the file slices for client access.

In order to illustrate the scalability, applicability and advantages ofthe afore-mentioned system and method, a few applications will bediscussed.

First, we consider providing nodes and storage for TV Episodes usingAES-128 encryption in variants in which each active node stores at leastone slice of each file. Assume the network starts out with 1,000 activenodes and no one is allocating additional space to the network (A=0)(e.g., one slice of each file at each node). Assume that the networkinitially starts with 3,500 TV shows supplied by various differentowners. Based on a TV show's average respective file size (200 MB),there would be an average total of 700 GB Gigabytes (GB) of multimediafiles on the network. Since there is 1 slice per file per node, therewould be a total of 3,500,000 different file slices distributed betweenthe 1,000 nodes, and each slice would be allocated 0.0002 GB, or 200 KB.Each node would hold 3,500 slices (the same as the number of files onthe network). Therefore each node would be responsible for 700 MB worthof file slices. Due to the requirements for sustaining the network, eachnode would be responsible for maintaining all of the files on thenetwork. In this case, each node would be responsible for storing 700 MBworth of encrypted slices in a dedicated encrypted folder on theirdevice. As illustrated in FIG. 6a , if the number of nodes remainsconstant and the number of files increases from 3500 to 1,000,000, thefile size requirements per node will increase from 0.7 GB to 200 GBwithout compression.

As discussed above, if one or more clients join or leave the network,the number of “slices” gets readjusted so that each client maintains anequal number of “slices” (all the work is evenly distributed across thenetwork). The more clients that join in proportion to the number offiles on the network, the smaller each individual file slice becomes,and the less space each Node needs to allocate to the slice network. Asillustrated in FIG. 6b , if the number of files remains constant at 3500and the number of nodes increases from 1,000 to 1,000,000, the file sizerequirements per node will decrease from 700 MB to 0.7 MB and the slicesize will decrease from 200 KB to 0.2 KB without compression. FIG. 6 Cillustrates the case were the number of files and the number of nodesincrease. Additionally, if a node opts to allow additional storage spacefor the network, the minimum file size requirement per node is reducedby A, and that node gets rewarded accordingly in slice currency.

As a second example, we will consider providing nodes and storage forsongs using AE-125 encryption in variants in which each active nodestores at least one slice of each file. In this illustration, we willassume that the average file size per song 3.5 MB (Uncompressed), thatthe network initially has 1,000 active nodes, and that the networkinitially holds 100,000 songs supplied by various different owners.Based on the average file size per song, there would be 3500.00 GB ofsong files on the network of 1,000 Nodes. Assuming no node allocatesadditional space (i.e., there is 1 slice per file per node), there wouldbe a total of 100,000,000 slices on the network. Each slice would beencrypted using AES-125 encryption to allow for smallest possible fileslice size, and each slice would be compressed using a 10:1 compressionratio (done before encryption). Accordingly, each slice would beallocated 3.5 KB and each node would be responsible for allocating 350MB worth of space to the network. As illustrated in FIG. 7A, if thenumber of nodes remains constant (1000) and the number of filesincreases from 100,000 to 80,000,000, the file size requirements pernode will increase from 3.5 GB to 2800 GB without compression. Asillustrated in FIG. 7b , if the number of files remains constant at10,000 and the number of nodes increases from 1,000 to 1,000,000, thefile size requirements per node will decrease from 122.5 MB to 00.1224MB and the slice size will decrease from 35 KB to 0.035 KB withoutcompression. FIG. 7 C illustrates the case were the number of files andthe number of nodes increase.

As a third example, we will illustrate, from the perspective of the userand the owner, how a transaction is processed.

From the User's Perspective: A user wants to purchase and access amultimedia file located on the network. In order to do so, the userdownloads and installs a Client Graphical User Interface (GUI) for thesystem. Upon installing the software, the user then automatically beginsacting as a user node, allocating the calculated minimum storage spacefor “slices” on the network, reducing the overall individual load of thenetwork. After installing the software and creating an account, a walletaddress is generated (in the background) which enables users to depositfunds with which to purchase the desired file. The wallet's address ishidden from the client, and a balance in the fiat value of slicecurrency in the wallet is shown as an account balance. Once the walletaddress is generated and connected to a specific account the userdeposits fiat currency using debit, credit, or bank account. Upondepositing fiat into their account, the money gets automaticallytransferred into the equivalent value of slice currency using theback-end server. When the user buys the file, they transfer the fiatequivalent value of the price in slice currency to the owner (through ablock-chain transaction), and unlock the file for the predetermined timeperiod as described above with respect to FIGS. 3-5. The wallet can beimplemented as a conventional digital currency wallet, such as thoseprovided as bitcoin wallet or ethereum wallet described above.

From the Owner's Perspective, an owner uploads their files onto thebackend server, which then get sliced and distributed to all of theactive nodes. The owner sets a price using a web interface or GraphicUser Interface for each file uploaded and attributes the price to apredetermined access time. For example, a musician could upload one songand set the price of $0.01 for an access time of the length of the song.This would set the price of the song per stream at $0.01. When a userpurchases their song, the musician gets transferred the $0.01 worth ofslice currency minus the exchange rate into their account balance. As anexample, the exchange rate may have a base value of (4%) but may also beflexible based on the specific owner (e.g., a sliding scale based onvolume). As an example, the more songs streamed, the higher the exchangerate (up to a maximum of 7%), and the less songs streamed the lower theexchange rate (down to a minimum of 1%). As described above, when thetransaction between a user and an owner occurs, block chain (ordistributed ledger) transactions are initiated in a conventional manner,and then processed by miners and published on the public block-chain.

It should be noted that although the system is described above in thecontext of separate user nodes and owner nodes, it is of course alsopossible to provide a single GUI which provides both user and ownerfunctionality. In other words, a node could function as both a user (forpurchasing and using content) and an owner (as a content provider).

A number of incentives can be built in to the system. For example, UserIncentives may include: rewards for storage size contributions to thenetwork; free access to multimedia based on generated slice currencyfrom size of files stored (or payment in fiat currency if slice currencyis exchanged for money rather than multimedia access). In other words,the users are rewarded for using software with free multimedia tokens,which can be exchanged for fiat currency. Promotions, offers, and dealsmay also be provided to encourage growth and popularity. OwnerIncentives may include: control over the price of their digitalintellectual property; security of their intellectual property throughproprietary encryption and block-chain system; the transparency of theblock-chain ledger; an instantaneous and secure payment system; adecentralized storage network; the potential for instantaneous feedbackfrom users through the system or other options for collaboration withusers. The system also provides systematic incentives to both users andowners, which may include: Rewards for miners to process transactions,based on volume of processes transacted; and rewards for miners forallocating storage space.

As discussed above, price information for the file, time of access forthe file, and timestamp (of when the file was sliced and/or purchased),and preferably the assembly information for a file, are published on theblock-chain as a block-chain transaction. This information could be in asingle transaction, or in separate transactions. In addition,conventional block-chain transactions are published on the block-chain,for example, payments for files, payments for mining, payments for slicestorage. In any event, the block-chain transactions are then mined ateach node in a conventional manner. Exemplary flow charts for mining theblock-chain are shown in FIGS. 8 and 9. These steps are performed ateach of the nodes 10, 20.

At step 200, a node (10, 20) receives block-chain transactions. The nodeverifies if the transaction is valid (210) and after receiving a numberof block-chain transactions bundles the transactions into a proposed newblock (220). The node then selects header of the most recent block onthe block-chain and inserts it into the new block as a hash with anonce, and then solves the proof of work or proof of stake problem(230). Once the proof of work or proof of stake problem is solved, thenthe new block is added to the local instance of the block chain at thenode, the new block is propagated to the network (240), and the node isrewarded in slice currency for mining (which reward is itself laterrecorded via a different block-chain transaction).

The proof of work or proof of stake process (230) is illustrated infurther detail in FIG. 9. The proposed new block is combined with theheader of the most recent block (232) and a nonce (233) (a number thatis incremented) and hashed (234) to generate a hash number. The hashnumber is then compared with a target value (235). The target value istypically a 256 bit number which is changed periodically (e.g. every2016 blocks) to maintain a preselected level of difficulty. If the hashnumber is less than the target value (235), then the proof of work orproof of stake is considered solved, and the hash number is the newblock (236). If the hash number is not less than the target value (235),then the nonce is incremented and the proposed new block is againcombined with the header of the most recent block (232) and a nonce(233) and hashed (234) to generate a new hash number, and the processrepeats itself until the hash number is less than the target value.

In the preceding specification, the invention has been described withreference to specific exemplary embodiments and examples thereof. Itwill, however, be evident that various modifications and changes may bemade thereto without departing from the broader spirit and scope ofinvention as set forth in the claims that follow. The specification anddrawings are accordingly to be regarded in an illustrative manner ratherthan a restrictive sense.

1-6. (canceled)
 7. A computer implemented method of securely managingfiles among a plurality of computer nodes connected to a server over aninternet, comprising the steps of: (a) receiving a plurality of filesfrom one or more of the nodes; (b) determining a number of the pluralityof nodes currently connected to the server; (c) for each of theplurality of files: dividing the file into a number of unique slices ofpredetermined size, encrypting each of the unique slices, distributingthe unique slices to the currently connected nodes such that nocurrently connected node receives all of the unique slices; and (d)Repeating steps (b) and (c).
 8. The method of claim 7, wherein in thedividing of step (c), the number of unique slices is equal to at leastthe number of nodes, and wherein in the distributing of step (c), eachcurrently connected node receives at least one of the unique slices. 9.The method of claim 7, wherein the plurality of files are media filesselected from audio files, video files, text files, image files, andaudio-video files.
 10. The method of claim 7, further comprising thesteps of: (a) receiving a request for a first file of the plurality offiles from a first node of the plurality of nodes; (b) transmitting aprivate encryption key to the first node; (c) retrieving the uniqueslices corresponding to the first file from the currently connectednodes; (d) decrypting the unique slices; (e) accessing assemblyinformation for the first file; (f) reassembling the unique slices intoan instance of the first file; (g) encrypting the instance with a publickey associated with the private key; and (h) transmitting the instanceto the first node.
 11. The method of claim 10, wherein prior to step c,the method includes receiving payment for the instance incrypto-currency.
 12. The method of claim 10, further comprising thesteps of transmitting the assembly information to each of the pluralityof connected nodes as a distributed ledger transaction.
 13. The methodof claim 12, wherein the distributed ledger transaction includesinformation indicative of a price of the first file.
 14. The method ofclaim 10, wherein a viewing limit is associated with the first file, andwherein the method further includes destroying the instance when theviewing limit is exceeded.
 15. The method of claim 10, furthercomprising transmitting payment in crypto-currency to an owner of thefirst file, where the step of transmitting payment comprises sending adistributed ledger transaction to each of the connected nodes.
 16. Themethod of claim 10, further comprising transmitting payment incrypto-currency to an owner of each of the plurality of nodes, where thestep of transmitting payment comprises sending a distributed ledgertransaction to each of the connected nodes, wherein an amount of saidpayment is proportional to an amount of storage on each node allocatedto storing the unique slices.
 17. The method of claim 16, wherein thepayment is also proportional to an amount of distributed ledger miningperformed by each node.
 18. The method of claim 10, further comprisingtransmitting payment in crypto-currency to an owner of each of theplurality of nodes, where the step of transmitting payment comprisessending a further distributed ledger transaction to each of theconnected nodes, wherein an amount of said payment is proportional to anamount of distributed ledger mining performed by each node allocated tostoring the unique slices.
 19. Non-transitory computer readable media,having stored thereon, computer executable process steps operable tocontrol a computer to perform the steps of claim
 7. 20-29. (canceled)